In this final lesson on the browser window module, we'll take a look at the Web content property of
the browser window module.
Very importantly, the Web content property is a module in itself, despite being a property of browser
window, hence it having its own dedicated lesson.
The best way to think of a Web content instance then is that it represents the content loaded into a
browser window.
So the browser window is where our content gets loaded into being acromion browser instance and then
that very content being the web content.
As will be working with the Web content of our main window in this lesson, I'll start by creating a
reference to that property.
Let see for Web content, equal main window DOT Web content saves us having to reference the full browser
window dot web content each time.
Comment out the dev tools for now and log out this new web content variable.
For the remainder of this lesson, I'll bring my terminal window onto my desktop to avoid switching
so to make space for that window.
I'm also going to shift the starting position of our main window to the left of the screen setting on
the browser window constructor, an X property of 100 and a Y property of also 100, meaning launch
this window 100 pixels from the left of the screen being the x axis and 100 pixels from the top of the
screen being the y axis.
I already have the app running with the watch command, so save there.
We see in the terminal our main window instances web content object being locked out with main window
launching 100 pixels into the screen with our web content instant referenced.
Let's jump into some useful functions and events of this module.
Again, this is a very large API, but for the most part it's a standard node event emitter, just like
the electron up instance or a browser window instance.
And many of the events and functions will be familiar or self-explanatory.
To start, we see a few simple static methods listed again, familiar, get all Web content, get the
currently focused Web content, or get a specific Web content instance from its ID.
Now, as mentioned, Web content is a module in itself, despite being a property of the browser window
module.
So in order to access static methods, meaning methods not related to a specific web content instance,
we'll have to use the Web content module directly.
For example, logout web content dot get all web content.
Requiring this web content module, as with any other electron module.
Like this save.
And there we get the exact same log as before, except this time it's inside of an array.
This being as we only have that one Web content instance, I'll clear this.
Head back to the documentation, and if we scroll down a bit further, the next rather large section
is instant's events.
We've seen a few of these events directly on the browser window module.
But here we now get much more detailed events relating to the state of the content being loaded into
the browser window.
For example, did finish load versus Dom ready to similar events, but with significantly different
users.
I logged those out to demonstrate web content on did finish load.
Pass a callback in which a logout content fully loaded, so this event, meaning all of our content
is ready.
Duplicate this for domme, ready?
Logging out domme ready this time, signaling that the structure or document object model of the HTML
being loaded is ready, we might still have unloaded images, etc., but the structure is ready to be
interacted with.
I'll add a remote image to better demonstrate this open indexed HTML.
Using the place kitten service with a 500 by 500 image, so notice now that dome ready will fire as
soon as all of the HDMI is ready, including the image tag, but did finish load will only fire once
the image content is also loaded.
I'll slow the recording down a bit to better demonstrate save Dom ready.
Fire's almost immediately as there is very little XHTML and then as soon as the image content loads
in did finish load.
Also fires meaning these web content events gives us way better control over the exact point of content
being loaded.
We also have several in between events like did Fallowed did start load or did stop load.
Then a bit further down we have this new window event, new windows being an important topic in an electron
up as we don't really want HDMI links to just create new windows without our permission, especially
when working with remote content, which is to be avoided wherever possible.
The default behavior then is for Electron to simply create a new browser window instance and load the
content for the new window into that window.
I'll demonstrate duplicate one of these listener's commenting about our content status events.
Change this event to new window, only to observe for now with the new window event, call back, providing
us the usual event object and the Eurail that triggered the new window.
So using that, our logout in an interpolated string, creating a new window for that call you oral
argument will also need a link to test this worth change the place, get an image to be a link instead
linking to that same image with an H3 text link of kitten.
Not forgetting the most important part of this link, a target attribute with a value of underscore
blank instructing the browser or browser window in our case to open this in a new window instead of
simply navigating to the link, save this and may not always click that new link.
And Electron automatically creates a new browser window with that image as its Web content.
We also have the log message from the new window event in the terminal pointing to that link URL.
So whilst this is very convenient, we don't have too much control over automatic new windows, which
is where the new window event can help us intersect the opening of new windows and handle it ourselves
instead.
Should that be the requirement for your specific app?
For example, in this event we can call on the event object prevent a default to instead prevent electron
from following the default behavior of creating a new browser window save.
Click that link again, and this time nothing happens apart from our blog message in the new window
event this way, then we can instead use this you Aurel, which would have triggered the new window
and instead load that content into a window of our own or do whatever else we like with it.
Much more control.
We also have other events for controlling navigation from standard links will navigate for catching
a link click before the content navigates to that new link.
Did start navigation, which will be immediately after a click or will redirect for intercepting redirect
triggered by links, we can also listen for Web contents becoming unresponsive, possibly using this
to inform the user of such events with a loader or something, or even when the Web contents crash,
allowing us to maybe manually reload the contents again.
Remember, the Web contents can hang in the renderer process and the main process will remain fine.
These events being good additions for distributed applications.
Then a bit further down, we see before input a very useful event for capturing user input.
Let's see this all duplicate this event again.
Comment out the old one.
Listening on before input event, which provides us in its call back the event object and the input
object, this input object containing a whole lot of information about the user input captured, for
example, are logout input dot key, followed by the input dot type save.
I'll press that a key on my keyboard and their two events get logged first, the ikki being pressed
down, being called key down and then immediately after for the same key key up being when I released
the key press enter and time.
So an extremely useful event for checking or even changing a user's input.
Next, we see some events for knowing when a user opens, the dev tools panel focuses it.
And so on note that most apps will, of course, not enable dev tools in production.
This will only apply to hackable apps like the ATM.
Ed, I'm using for this course some SSL certificate events and for working with HTTP authentication.
We have this login event.
For anyone not familiar with basic auth, it's essentially a way to secure HDB with a simple username
and password.
I've linked to some good articles explaining it in more detail in the lessened resources.
Essentially, when a user attempt to visit a quarrel with basic HTP authentication, the browser will
prompt the user for a username and password in an electron app.
However, that's not going to be how we handle authentication.
So instead we can allow the user to load secure content by listening for a login event and then authenticating
on their behalf.
Let's see a simple example to do this, we all have to load some content with HDB authentication, so
comment out our main windows load file function adding instead lodeiro with this HTP Bennu url HDB Ben
is a simple service that allows us to test all manner of HDB features.
This link is in the lessened resources.
This URL then requires a username and password or else will get refused with a four to one unauthorized
status code.
So before actually authenticating this, let's first see a failed authentication.
We can get the response code using another web content event I've already mentioned did navigate being
the event that fires after a page, navigate it, be that via a link clicked or content being loaded.
The event provides us a few arguments in its callback.
The event object the Eurail to which the navigation happened, a status code and a message.
I lock those out.
Navigated to you are.
And a second look with status code.
And we get the unauthorized log as the secure content fails to load, so let's handle this login event,
web content on login with the callback exposing the event object, the request object of info and finally
a callback function we can use to perform the authentication with our log out logging in as soon as
this event fires and then proceed to log in with the event callbacks provide it function this callback
argument calling callback with the username as the first argument being user and the password as the
second password.
That's it.
There should now fire as soon as the basic auth happens, perform the authentication and then proceed
to load the content, which in turn will fire this dead.
Navigate with a success status.
Save.
We see logging in and a moment later, the Jason from this HDB, but an end point load's showing us
a dead navigator with a 200 status code, basic of being a very unlikely problem for most apps.
But should you want to provide your app with some secured remote data?
This is a great and simple solution.
A bit further down, we see an event for retrieving search results in a content search that's being
initiated with the find in Page Instant's method and some media events for knowing the state of video
or audio in the content.
Let's see a simple example of this.
I'll comment about these off.
And did navigate events.
Add a video file to the project for us to test with MGM dot MP for a small and before video file.
This file is in the lesson directory.
Should you want to use the same one?
So what we're going to do here is embed this video in our HTML Index DOT HTML and listen for play and
pause events, web content on.
Media started playing.
In which all analog message with video started.
Duplicate that.
This time, listening for media, paused, logging out video paused at that video to indexed HTML,
I'll replace the kit EnLink using a video tag with source current directory MGM dot MP for I don't need
these adding video controls with the controls attribute and a width of 650, we still need to change
the content back to loading indexed on HTML.
Comment out the HDB Bunyoro done save.
We see that video loading and when I start the video the first event gets triggered.
Pause.
The video video paused.
So a really simple listener for knowing when a user's interacting with media in your content.
The next very important event I'm going to demonstrate is this context menu event.
This being when a user.
Right.
Click on something now as far as actual menus go, will cover that in an upcoming lesson.
But this is an important event to understand as users quite often right click for various reasons.
First thing to notice is that this event, despite having only two arguments on its callback, contains
a lot of data on the second programs.
I'm going to demonstrate a basic example of accessing this.
I'll duplicate one of these events again, commentor these listening on our Web content instance for
context menu use to provide a callback arguments, event and programs.
And what I'll demonstrate is how to check, for example, whether a user clicked on a media element,
what type of media it is, and where the user clicked in the app, an X and Y coordinate.
So logout context menu opened, meaning the user right clicked on programs.
Dot media type at X programs dot x, y.
Param Stot, why?
Save.
Perform a right click on that video element and there context menu opened on video at X and Y being
exactly where the click happened.
So a second click on a different point, having a different X and Y coordinate.
Equally useful, we can also check whether a user selected some content when the right click happens,
change this log to user selected text.
Forums, dot selection text, and should a user have some selected text?
Are we able to copy the text useful for knowing whether to show a user the copy command in the context
menu?
Again, we'll see how to create these on the right click later.
Selection can be copied.
Per Ramsgate edit flags dot can copy.
Save.
I'll select this heading.
Right, click and their user selected selection can be copied, true, so already we're able to access
HTML content from the Renderer directly in the main process.
Back in the docks, we have a few more events with the next section being instance methods, some of
which we've already seen load euro and load file.
Of course we are calling these on the browser window instant's not the Web contents of that browser
window, but essentially it's the same with Web content being a property of browser window.
A lot of their methods are shared.
We can also initiate, download, focus a web content instance or reload the content manually, perform
manual navigation with go back and go forward and an extremely useful instant method, execute JavaScript
in the web content.
Let's see an example of this.
Let's say we somehow want to make use of this selection text we got in the context menu event, but
do so in the web contents.
I'll assign the selection to a variable selected text equals parameter selection text calling on the
web content.
Execute JavaScript with the code alert.
Selection text, meaning on the Web contents, so the front end, so to speak.
Call the browsers alert function with any selected text when a user right clicks.
Save this.
Select that same heading again, right click.
And there we get an alert with selected text, another simple example of data crossover between the
main process and the renderer.
Of course, this web content object contains many more functions and events.
But having seen these few, you'll be able to use all the others easily enough.
Things like copy, paste, undo, redo and many more.
As with the browser window module, I'd encourage you to have a look through all the available events
and methods so you know what's available when building your own app.